feat: add a per step forced discharge demand - #138

@ekkea all three addressed in 91b6186, and the branch is merged up with main.

• Overlap: a step with both p_demand and d_demand above zero is a 400, not a 500. It is a client error like a length mismatch, and the response names the battery and the steps.
• SoC: z_s_min_reached releases the demand once the battery sits at s_min, the same construction as z_s_max_reached for the charge demand. test_discharge_demand_stops_at_the_s_min_reserve asserts the penalty variable is zero there.
• Standard cases: test_cases/029-forced-discharge.json and 030-forced-discharge-stops-at-reserve.json, both strict so the schedule itself is compared.

🤖 Generated with Claude Code

Solve time, stored cases, three runs each, median, on this branch.

Requests without d_demand are unchanged: the model is untouched, the only addition is an O(T) overlap check in the parser. All 20 stored cases take 5.2 s on main and 5.4 s here, noise.

Requests with d_demand pay for one binary per demand step, z_s_min_reached. The control row has discharge_to_grid on but no demand, so the flag itself is separated out.

This is the price of the #95 construction, not of the mirror. p_demand at the same density on the same battery, c_max/4 every fourth slot, costs 9.3 s on 028 and 9.3 s on 020. The stored cases never show it because their p_demand sits on batteries with 36 to 77 kWh against 11 kW, so the demand is always servable and the relaxation never needs the binary. Stress either demand against a battery that runs out and branch and bound pays the same.

The weakness is the big-M relaxation: z goes fractional in proportion to the distance from the bound, so the relaxation releases half the penalty at half capacity. A release without a binary needs min(demand, available) as a lower bound, a disjunction, so there is no cheaper exact form. Dropping the binary brings back the lingering penalty and with it the solver grid charging the battery to serve the forced export, the mirror of what #95 fixed.

What remains: the evcc side sends d_demand only for slots at or above the feed-in limit with the opt-in set, a few hours a day, so the 2 h per day row is the realistic one. Replanning every cycle also allows capping the demand to the nearest slots there. OPTIMIZER_TIME_LIMIT is unset by default and would turn a long solve into a Feasible result instead of a stall.

🤖 Generated with Claude Code

Two alternatives to the per step release binary, prototyped on this branch behind a switch, three runs each, median. Controls without any demand: 028 at 2.3 s, 020 at 1.5 s.

Monotone release keeps the binary and adds z_t >= z_{t-1} inside a demand block. Halves the 4 h case on 028, nothing on the every-4th case, mixed on 020, and it would keep a battery released after PV refills it mid block. Not worth it.

Export bonus drops the binary and the penalty: d_bonus <= d, d_bonus <= min(d_demand, d_max dt), and the objective gains (max(0, p_a - p_E[t]) + 0.1 penalty_base) * d_bonus in the demand steps. Pure LP. Realistic patterns land at the no-demand control. Cases 029 and 030 produce the identical schedule and objective, so served, clipped to d_max, stop at s_min and no-sink all hold, and an empty battery has nothing to earn, so the pathology the binary guards against cannot occur.

Two caveats. The adversarial every-4th 028 case goes to 70 s, all in the joint stage: the bonus interacts with that case's peak attenuation and p_demand binaries rather than adding its own. And the semantics shift from forced to preferred: the solver skips a demand slot when serving it costs more than the bonus. On 028 that gave a clean objective of 4.98 against 4.30, some forced exports the binary version performed were dropped.

The same trade exists for p_demand: a charge bonus on grid-to-battery energy in the cheap slots would replace z_s_max_reached and z_p_demand, with the same shift to preferred.

My take: the bonus fits d_demand, the evcc grid discharge limit is a preference by nature and its slots are few. p_demand stays as is until its own cases show the cost. @ekkea if you agree I replace the binary here with the bonus and regenerate the two cases.

🤖 Generated with Claude Code